fix: throw when encoding a BigInt outside int64/uint64 range#290
Open
spokodev wants to merge 1 commit into
Open
fix: throw when encoding a BigInt outside int64/uint64 range#290spokodev wants to merge 1 commit into
spokodev wants to merge 1 commit into
Conversation
With `useBigInt64: true`, `encodeBigInt64` branched only on sign and
called the native `DataView.setBigUint64`/`setBigInt64`, which truncate
mod 2^64 without throwing. A BigInt outside the representable range was
silently corrupted on encode:
encode(2n ** 64n, { useBigInt64: true }) // decoded as 0n
encode(2n ** 64n + 1n, { useBigInt64: true }) // decoded as 1n
encode(-(2n ** 63n) - 1n,{ useBigInt64: true }) // sign flip: 9223372036854775807n
The MessagePack int family is fixed 64-bit, so the only representable
range is the union of int64 and uint64: [-2^63, 2^64 - 1]. Add a range
check that throws for anything outside it, matching how the encoder
already rejects other unrepresentable inputs (too-long strings, too-large
arrays/maps/binaries).
Comment on lines
292
to
+294
|
|
||
| private encodeBigInt64(object: bigint): void { | ||
| if (object < -(BigInt(2) ** BigInt(63)) || object > BigInt(2) ** BigInt(64) - BigInt(1)) { |
There was a problem hiding this comment.
Suggested change
| private encodeBigInt64(object: bigint): void { | |
| if (object < -(BigInt(2) ** BigInt(63)) || object > BigInt(2) ** BigInt(64) - BigInt(1)) { | |
| const INT64_MIN = -(BigInt(2) ** BigInt(63)); | |
| const UINT64_MAX = BigInt(2) ** BigInt(64) - BigInt(1); | |
| private encodeBigInt64(object: bigint): void { | |
| if (object < INT64_MIN || object > UINT64_MAX) { |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
With
useBigInt64: true,encodeBigInt64branches only on the sign of the value and calls the nativeDataView.setBigUint64/setBigInt64. Those methods truncate the value mod 2^64 instead of throwing, so aBigIntoutside the representable range is silently corrupted on encode:No error is raised, so the caller has no way to notice the data loss.
Fix
The MessagePack int family is fixed 64-bit, so the only representable range for a
BigIntis the union of signed int64 and unsigned uint64:[-2^63, 2^64 - 1]. This adds a range check inencodeBigInt64that throws for anything outside that range, before the writes.This matches how the encoder already rejects other unrepresentable inputs (too-long strings, too-large arrays/maps/binaries all throw rather than emit corrupt bytes).
Tests
Extended
test/bigint64.test.ts:0n,42n,2n ** 63n - 1n(max int64),-(2n ** 63n)(min int64),2n ** 64n - 1n(max uint64)Full suite: 329 passing, lint clean.